\section{Related work}
\label{sec:related_work}

\subsection{Attacks}
\label{sec:rel_attack}

Several attacks motivate our work.  The confused deputy problem is introduced in \cite{Hardy:1988:CD:54289.871709}.  Much previous work has been done on exploiting race conditions in file operations.  TOCCTOU vulnerabilities in the Linux file system are discussed in \cite{wei2005tocttou}.  Work on concurrency attacks is done in \cite{Yang:2012:CA:2342788.2342803}.  Race conditions and exploitations are given in \cite{Dean:2004:FRF:1251375.1251389}.

Name resolution is also a deep topic, with many papers developing vulnerabilities and demonstrating attacks.  Name resolution attacks are covered in \cite{conf/ndss/ChariHV10,ec2nd11-vijayakumar,Cai:2009:EUF:1607723.1608123}.  An adversary is developed in \cite{Vijayakumar:2012:SFN:2362793.2362834,conf/ndss/ChariHV10}.

%More general file system security is covered in \cite{Halcrow_demands}.

\subsection{Defenses}
\label{sec:rel_defense}

Other work on defending against TOCTTOU is done in \cite{tsafrir2008portably,pu2006methodical}.  Protocols for programs to check for race conditions are given in \cite{bishop1996checking,Lhee,Uppuluri:2005:PRC:1066677.1066758}.  Runtime detection of race conditions is covered in \cite{Tsyrklevich:2003:DDP:1251353.1251370,Yip:2009:IAS:1629575.1629604,bishop1996checking}.

Closely related to our work is \cite{Payer:2012:PAA:2365864.2151052}, where file metadata are cached and used to prevent TOCTTOU in user space.  Similar work on a database inside the kernel is done in \cite{Kashyap04filesystem}.  The idea of kernel-level protection from race conditions is covered in \cite{Cowan:2001:RKP:1251327.1251340,Zhai,LosSma2001}.

Reference monitors as a concept have received much attention.  A reference monitor for Linux is detailed in \cite{Wright02linuxsecurity,Watson:2001:TAT:647054.715753,smalley:01}.  A chapter on extending the reference monitor concept to prevent race conditions is included in \cite{Aizawa}.  Extending the reference monitor with role-based attributes is done in \cite{DBLP:conf/pacis/YongBTR06}.  A microkernel-based solution to including a reference monitor is done in \cite{Kyle:2007:ULS:1314354.1314371}.

Support for policies when arbitrating references is done in \cite{Loscocco:2001:IFS:647054.715771,Hicks:2007:LSA:1266840.1266854,conf/usenix/Grunbacher03}.  Extending the threat model to include purpose-based access control is covered in \cite{Byun:2005:PBA:1063979.1063998}.

\subsection{Auditing utilities}
\label{sec:rel_audit}


Many papers and commercial systems exist for file auditing, tracking, syncing.  Backup and syncing are covered in \cite{Nishimura:2010:ISF:1923661.1923666,Braam,Langford01multiroundrsync,Rosenblum:1992:DIL:146941.146943,Ts'o:2002:PEL:647056.715922,bram2009snapfs}.

Several frameworks exist for recording file system activity without modification to the kernel.  The $inotify$ hook provides an upcall into user space to allow recording of file system modification \cite{Robert:inotify}.  This can be used to index the file system for searching, as done by Beagle on many Linux distributions, but does not provide the extended information needed here.  A more appropriate framework has been developed within the context of system administration.

The $audit$ framework
%<<auditd papers>> 
is a user-level auditing system that is packaged with most Linux distributions.  The $auditd$ program is often used to track file changes, accesses and even system calls.  An extensive set of features supports detailed analysis of file history and behavior.  Administrators are required to set up auditing rules, which specify the scope for auditing, like file path or permissions.  Once the scope of the audit is set, the auditd daemon monitors the specified scope.  If the supplied watch path is a directory, all changes to that directory (including subdirectories) are recorded by auditd automatically.  The audit log is sufficiently fine-grained that administrators are able to track each file access by time, username, executable binary or type of access (read, write or execute).

This additional information is sufficient to implement the total file history described above.  Thereby it is made much easier to realize the defensible assignment of differing trust classes to the files - the labels upon which a SELinux-like security module ultimately relies.  However, to record this additional information for each file requires extending the default UNIX attributes.  Extending the Linux file system to support extended attributes has been done in \cite{Watson:2001:TAT:647054.715753,Kashyap04filesystem}, as well as the Fast File System (FFS) of the FreeBSD operating system.
%<<FFS papers>> 

%Ultimately, the goal of all of this recording activity is characterization of the files found on the system at a given moment.  To do so requires taking a snapshot of the file system.  Snapshot tools often rely on detecting differences in files
%<<rsync algorithm paper>>
%.  Others detect changes in file attributes
%<<file synch papers>>
%.  Some tools have already been developed to take file system snapshots
%<<academic snapshot papers>>
%, and several production products exist
%<<open source snapshot papers>>
%.

%SnapFS \cite{bram2009snapfs} provides a good concept when tracking file modifications.  In SnapFS, a snapshot is a frozen image of a file system, which keeps file attributes, file contents and directory layout.  It is also easy to find how files are changed between snapshots.  These details can be even more fine-grained than those provided by auditd, as auditd only records a file-change event, but SnapFS can provide detailed information as to the changes made to a plaintext file.  In fact, most configuration files are plaintext, so knowing how these files are modified is helpful when determining whether these remain trusted.  Moreover, snapshots make rollback possible.  Therefore, if a system suffers from some malicious modifications, SnapFS can quickly rollback the whole system to a trusted historical state.  Along with the audit logs, administrators should be able to figure out policy flaws or software bugs, which lead the system going wrong. 

%Although not intended for the purpose of file system versioning, Git is a version control system that can scale to the level of a large directory tree.  In fact, it can be adopted to implement a SnapFS.  The only intrusion on the file system is to add a subdirectory directory named $.git$ in each directory.  For better scalability, administrators can configure Git to track only certain files (e.g. configuration files) rather than the whole file system.  With each commit, Git makes a snapshot of what it is tracking and assigns a commit number to the snapshot.  However, Git only records the changes to the previous commit rather than the whole image, which makes storage use more efficient.  Git can not only list what files are added or deleted but also what content is added to files, which would be helpful when manually checking trustfulness of certain files.  Like SnapFS, Git can also rollback the current system to any historical commit quickly.  Therefore, Git is in most ways a competitive alternative to SnapFS.

%TODO: Find papers on xattr and trust classes

% Recent generations of file systems had gravitated to a log-structured design \cite{Rosenblum:1992:DIL:146941.146943,Ts'o:2002:PEL:647056.715922,Halcrow_demands}.  This greatly aids the task of recording logs of file modifications.  

% FFS permits files and directories to be continuously associated with new meta-data such as access control lists, capability sets, and mandatory access control lists.  Extended attributes allow the file system to support a class of dynamic extensions requiring additional metadata without changing the on-disk storage format.  User-space processes can also use the extended attributes through additional system calls that modify the extended attributes for files and directories.



